home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 7
/
Aminet 7 - August 1995.iso
/
Aminet
/
comm
/
term
/
XPRZ35R.lha
/
docs
/
xprzedzap.doc
< prev
next >
Wrap
Text File
|
1994-11-26
|
9KB
|
208 lines
XRPzedzap.doc by Robert Williamson
XPRzedzap.library is an enhanced version of xprzmodem.library for use in
FTN sessions. The xprzedzap.library uses the 3.1 version of the
xprzmodem.library as its base and uses the 0.85 version of
xprzedzap.library by Yves Konigshofer for FTN-related extensions. This
version was audited by Yves and released with his approval of myself as
KOTS for zedzap.
Since the version 0.55 sources were written for lattice C, I had
decided to forget about them AND the .85 and .90 sources and build a new
one from xprzmodem v3.1 source. This source is compilable with SASc v6.51
and uses the libent and libinit modules instead of the old latticelib
assembly stubs.
The new version has virtually all the useful xprzedzap v1.0 options and
features DirectZap as well and ZedZap, ZedZip, SZmodem and Zmodem. The
protocol currently active is displayed in the xpr status window.
Mailers and XPR Protocols
Many Mailers make use of XPR protocols to provide file transfer
capabilities and to gain the advantage of easy addition of new protocols
when they become available. Those known to use XPP protocols include:
POP, JAZ, RAP, UMBRELLA, GAZEBO, PORTICUS, ROOF, NORM and JAMMAIL.
Since Mailers perform a fast turaround from send to receive and
vise-versa, the XPR design must insure that both echoed characters and any
left unread from the previous transfer do not cause detrimental effects.
While the changes to avoid these problems will not affect term programs and
BBS's using xprzedzap.library, the lack of these 'fixes' in
xprzmodem.library make it near useless in mailers.
Mailers require that a session can be accomplished without reporting a
failure if there were no files sent and/or received. The enhancements in
XPRzedzap.library address this problem.
Mailers also require notification of the status of each file transfer
in a batch. This is provided by the XPR 3 function upd_status().
Calculation of CPS and expected transfer times are based upon the baud
rate. If the mailer does not set this to the linked rate, the calculations
will be based either upon the Locked rate or the prefs setting. The
C<baud> option allows passing the LINK rate for more accurate and realistic
results.
The maximum packet size can be set with a maximum/default at 8192 and a
mimimum of 64. This will vary when sending and will be static when
receiving. When receiving, it should be 8192 but the maximum packet size
can be set to less than if the local system has a slow HD.
When sending the maximum packet size will be baud rate dependant, and the
size is calculated with the formula:
MAX_PACKET = (BPS_RATE * 8192 / 9600).
If C(baud) is passed, the link rate will be used for these allocations.
The IO Buffer for reading/writing to/from the disk must be equal to
twice the maximum packet size (or the maximum packet size will
automatically be decreased).
Example Protocol Setups for xprzedzap.library and Mailers:
The defaults for xprzedzap.library are set in such as way as to require
minimal changes for each protocol.
TN No Text translation
OR Overwrite Resume
B16 Buffer size 16KB
F0 Frame size = filelength
E30 Error count 30
SN Do not send full directory path
RN Do not use received full directory path
AN Disable Auto-activate mode
DN Do not Delete after sending
KY Keep partial files
P"" Comm progrmas provides Path to use for received files
M8192 Maximum packet size 8K
C0 Set Link BPS Rate
NY Alow Send if there are no files
QN Disable DirectZap escape only CAN
ZY Enable FTN mode
Zmodem used for user uploads/downloads (GRAB, for example)
M1024,ZN,C$(Baud)
SZmodem It is possible that M8192 will work if the user is using
SZmodem or 8K-Zmodem.
M8192,ZN,C$(Baud)
DirectZap uses 8K blocks, allows NoFiles transfer, escapes only ZDLE
and ZDLEE
QY,C$(Baud)
ZedZip uses 1K blocks, allows Nofiles transfer
M1024,C$(Baud)
ZedZap up to 8K Blocks, allows NoFiles transfer
C$(Baud)
If your mailer does not support inbound RESUME, you must add 'ON'
(OverWrite Never) to the setup string in order to override the default 'OR'
(OverWrite Resume) and 'KN' (Keep Never) to override the default 'KP' (Keep
Partial).
The New Setup options:
Z - FTN mode
The Z option enables FTN operation, when Y, the following is in effect:
- RxTimeOut is restored to 600ms
- transfers start with blocksize specified in M option.
- serialbuffer is cleared before sending/recving. In FTN
mode the turnaround from sending to receiveng (and vis-versa)
is quite fast, clearing the buffer avoids reading echos of our
own characters or leftovers from the previous transfer.
- affects selection of protocol name
C<link bps>
Buffer allocations and calculations of CPS will be based upon LINK rate
if passed with C<baud> option, otherwise they will be based upon the
LOCKED rate.
N - send no files mode (DirectZap, ZedZip and ZedZap protocols)
It is permitted to have a session without sending or receiving files if
N option is Y. This is required with some protocols in FTN mode so as
not to generate a spurious failure after a mailer session. This also
chnages EOF mode from sending CAN's to just sending ZFIN.
Q - DirectZap mode
Only ZDLE adn ZDLEE will be escaped is Q option is Y (DirectZap protocol)
Status Display:
XPR 2.001 support for dual-status windows added. (tested, but note
that there is no publically available version of wpl.library that supports
this)
Protocol name displayed will be one of:
Zmodem, 1K blocks standard, up to 8K, non-ftn mode
ZedZap, up to 8K Blocks based upon bps rate, ftn mode
ZedZip, 1k blocks , ftn mode
DirectZap, up to 8k blocks, minimum escaping, ftn mode
Added localization for new options. These are NOT translated for
german catalog, so that catalog has been removed from distribution.
During batch transfers, Error message field is set to "None" when
starting to send or receive next file.
wpl concerns:
XprSetup does not read any variables, so you must set option C to
$(baud) so that all calculations are based upon the actual link rate and
not the locked rate.
XprSetup makes an XPR library ready for a transfer. The first parameter
given is the xpr library name, and the second parameter is a string passed
to the xpr library with XProtocolSetup(). The variable $(XprSetup) is set
to the numeric return of XProtocolSetup(). A value of 0 indicates a
failure, otherwise the setup was successful.
Return Values in $(Setup) are or'ed from the following:
XPRS_FAILURE 0x00000000L
XPRS_SUCCESS 0x00000001L
XPRS_NORECREQ 0x00000002L
XPRS_NOSNDREQ 0x00000004L
XPRS_HOSTMON 0x00000008L
XPRS_USERMON 0x00000010L
XPRS_HOSTNOWAIT 0x00000020L
XPRS_NOUPDATE 0x00008000L
XPRS_XPR2001 0x00010000L *
XPRS_DOUBLE 0x00020000L *
* Note: private jammail versions of wl.library required both returned
to enable dual-status display. This is WRONG. Only XPRS_XPR2001 should
trigger use of dual-status display.
Normally returns:
XPRS_SUCCESS | XPRS_NORECREQ | XPRS_HOSTMON
| XPRS_DOUBLE | XPRS_XPR2001
or
XPRS_SUCCESS | XPRS_NORECREQ | XPRS_DOUBLE | XPRS_XPR2001
Return values in $(RC) are as follows:
0 - All OK.
1 - XProtocolSetup returned FALSE.
2 - Library not able to be opened
3 - Out of memory.
4 - Wasn't given required modem.
-Robert Williamson
Credits:
-Chuck Forsberg for the original ZMODEM specs
-Rick Huebner for the original xprzmodem.library (--> v2.10)
-William M. Perkins for the 32bit CRC improvements (2.50)
-Yves Konigshofer for the changes to allow ZedZap-type transfers
and a lot of advice by phone during the conversion process
-Rainer Hess for addition of locale support
Debits:
-Rainer Hess for NOT acknowledging Yves's development. Many features he
claimed he added first appeared in Yves's sources.